[レポート] qa不在のスクラムチームは品質向上の夢を見るか #jassttokyo

こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。

私は2024年3月14日~3月15日に開催されているJaSSTソフトウェアテストシンポジウム-JaSST'24 Tokyoに参加させていただきました。

今回は聴講したセッションのうち、qa不在のスクラムチームは品質向上の夢を見るか について私なりの概要やおすすめだと思ったポイントについてまとめたいと思います。

qa不在のスクラムチームは品質向上の夢を見るか

講演者

• 谷尾 虎之介 氏（ダイキン工業）
  • スクラムマスター的な立ち位置での目線で発表いただく
• 森鳰 武史 氏（ダイキン工業）
  • 開発チームからの目線で発表いただく

概要

以下はセッションの内容より引用したセッションの概要です。

弊社アジャイル内製化チームは未経験のメンバーで構成されながらも次第にスクラムチームとして成熟してきた。 しかし、プロダクト拡大に伴い不具合や障害件数も増大し、品質面の課題が浮き彫りとなった。 そこで我々はチームメンバーを主体に品質改善をリードする方針をとり、品質活動とスクラムとのシナジーを生み出すことで、チームの総合力で品質にコミットできるようにまで成長した。 本論では、どのようにこの相互作用を作り出しプロダクト価値に繋げたのか紹介する。

発表資料

2024年3月14日22時現在では公開がないようですので、発見したら更新させていただきます。

私なりの概要

講演中のメモをベースにしているため必ずしも正しくありませんが、私としては以下のようにセッションの内容を受け取っています。

まとめ

• まずはスクラムマスター目線での話から
• アジャイル内製化チーム(4名)からスタートされた
• チーム体制
  • 6人 * 2のスクラムチーム
  • 設計、開発、テスト、運用含めた職能横断型のチーム
• (一見)QA不在の世界で起こりそうなこと
  • バグの発見が遅れて、開発者も疲弊し、顧客からの信頼も低下し・・・みたいなことが起きそう
• 実際に起こったこと
  • 開発者の感性で書かれるテスト
  • テストは単体テストしかない
  • プロセスが改善しない
  • 品質に対してオーナーシップをあまり持てている人がいなかった
• QAとスクラムチームの関わり方よくあるパターン
  • スクラムチームの外部から関わりをかけてくれるパターン
    • （私の感想）
      • SmartHR基本機能のQAチームが開発チーム横断で品質保証活動をがんばっている話 - SmartHR Tech Blogのような状態かと思いました
  • スクラムチーム内部にQAをアサインするパターン
    • ISTQBも推奨していたり、他社事例も多い
    • （私の感想）
      • サイボウズの QAエンジニアについて / about cybozu QA - Speaker Deck のようにプロダクトのスクラムチーム内にQAの方がいるような状態かと思いました
  • 問題
    • そもそも少ないQAエンジニアでさらに、非IT企業ではもっといない
• 選んだ手法
  • QCというやり方。開発者が品質面でチームをリードする。
  • 勉強会の方向性や内容を策定したり
  • スクラムイベントでの品質計画を主導したり
  • チームの品質理解に責任を持つ
  • 主体的に品質活動を実施するのは開発チーム全員
  • 品質に責任を持つのも開発チーム全員
• チーム発足当時
  • 機能開発を優先、品質活動を後回し
• 対策としてやられたこと
  • 1 開発チームによる品質体系のサーベイ
    • JSTQBのAgile Testerシラバスの勉強会（輪読会？）を開催した
    • 探索的テスト
    • ポストモーテム
    • カオスエンジニアリング
  • 2 学んだ技術を実践する場を用意した
    • テストツールなどの導入
    • 使用しているOSSへのコントリビュートでツール自体を理解したり、使いやすくしたり
• PBIとして品質活動も同様に扱う
  • 品質改善の価値をスクラムチーム全員が理解
  • 品質活動に対するプロダクトゴールへの影響・優先度の議論
  • 改善スプリントの方向性が明確に
• 対策の結果: デプロイ頻度が増え、リードタイムが減少
  • 実際の資料では具体的な時間を表示してくださっていました

• ここからは開発者視点の話

• チームで認識したこと（QC導入以降）
  • 何が問題なのかがわからない
  • テストコードが煩雑でコードの変更が難しい
  • 特定の負債を避けた実装でいいのか
  • テストピラミッドが歪んでいると感じている
  • 問題を解決するための手段を知らない
  • レガシーコードに向き合う必要があるという結論になった
• 対策としてやったこと
• 1 レガシーコードに向き合う
  • 単にリファクタリングの手法とかいう意味ではない
  • リスクを潰す過程でプロセスを改善するチャンスと捉えた
  • クリティカルな部分を安心して扱えるようにする
  • 同じことを繰り返さないためにプロセスを改善する
  • スクラム経験主義 ためしてみる
    • やってよかったことを継続する方針で進めることに
    • クリティカルな部分を安心して扱えるようにする
    • 探索的テストで開発者が怖いと思う部分を調査
      • 様々な挙動を試す
      • ソースコードを確認する
      • 見つけた課題をPBIにいれる
    • 調査工数をかけてでも期待すること
      • 開発者のシステム理解がすすむことで
        • バグ修正工数が下がる
        • バグ発見率が上がる
• 2 同じことを繰り返さないためにプロセスを改善する
  • バグ対応後にすること
  • 致命的なバグ
    • 発生を抑える
    • ポストモーテムで再発防止
  • それ以外のバグは発見タイミングを早くする
    • 発見タイミングを早めることで手戻り工数を減らす
    • 受け入れ条件 < 単体テスト < 統合テスト < アラート < ユーザー報告
      • 左側のほうが発見タイミングが早い
    • 完成の定義も見直す
• 3 バグ発生後の対応を改善する
  • 毎月のカオスエンジニアリングで復元力を高める
  • 仮説検証結果
• チームのいろいろなことがよくなった
  • 先の通りリードタイムの削減やデプロイ頻度の向上

感想

• すごく赤裸々に最初に起こってしまった悲しいことについて説明いただきました
  • 会場でうなずきまくっていたのは私です
• またその取り組みに対してスクラムマスター的な視点、開発チームの視点からやってきたことや感じていたことを話していただいてくれたのが素晴らしかったです
• 個人の経験としても「QAエンジニアいない」があるあるなのですが、そんな中でも「開発チームで品質に責任を持つ」という点で実践されたこと・効果として実測されたことを発表いただけたのが素晴らしかったです
• スクラムチームで「アジャイルテスティングがわからない」「スクラムで品質って何から考えたらよいのかわからない」という方に良いと思いました
  • また、「本当に何をしたらよいかわからない。開発者の感性でテストを書いているんだけど・・・」という方には以下のようなブログ記事を呼んでおくことでより解像度が高くなるかと思いました
  • スクラムをうまく回すために受け入れ基準をきちんと書く - SmartHR Tech Blog